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IMPROVED USE AND MANAGEMENT OF GROUPS 
DEFINED ACCORDING TO A CALL INITIATION 

PROTOCOL 

Field of the Invention 

5 

The present invention relates to communications systems and more 
specifically to such systems that provide for establishing communications amongst 
a group according to a call initiation protocol within the system. 

10 Background Of the Invention 

Communications systems are known and such systems normally use some 
form of call initiation protocol. One such protocol is a session initiation protocol 
(SIP) and systems utilizing SIP have been contemplated. SIP is a general purpose 
protocol that aids in setting up communications between users or a group of users 

15 where the communications may use or require certain multimedia facilities or 
services (voice, video, etc.). SIP is a protocol that has or is being defined by the 
Internet Engineering Task Force (IETF). The basic specification for SIP may be 
obtained through the IETF website and is identified as draft-ietf-sip-rfc2543bis. 
Various other documents related to SIP are available through the same site. 

20 According to the SIP specification to make a group requires defining a SIP 

name for the group such as sip:groupl@domainB.net or org or etc (hereafter 
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denoted domainB). This name includes a user part and a domain part, here 
group 1 and domainB respectively. The server or registrar for domain B is now 
responsible for handling the mobility of each of the members of group 1. Mobility 
of a SIP group is handled like that of a normal SIP user. Basically the registrar of 
5 the responsible domain keeps one or more contacts or locations for each member 
or user that is a part of the group. For example, if userl was a member of groupl 
and normally available or located at hostl in domainA the contact under SIP could 
be of the form userl@hostl .domainA . 

When a caller wishes to contact groupl a SIP INVITE message is sent to 

10 domain B and the registrar of domain B forwards or redirects the INVITE message 
to each of the contacts it keeps for each of the members of this group. Mobility is 
handled under SIP with REGISTER messages. In known systems using SIP, when 
a user moves locations the user must send a REGISTER message to its own 
domain as well as the registrar of each group where it is a member. Various 

15 problems are evident with this approach. Each user must know all groups where 
it is a member and when this membership is large a large number of registration 
messages are required when the user moves locations. This requires extreme 
discipline on the part of users and the large number of registration messages can 
be expensive particularly in an environment such as wireless where bandwidth 

20 may be limited. Clearly a need exists for an improved methods and apparatus for 
using and managing group membership and mobility defined according to 
various call initiation protocols. 
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Brief Description of The Drawings 

The accompanying figures, where like reference numerals refer to identical 
or functionally similar elements throughout the separate views and which are 
5 incorporated in and form part of the specification, serve to further illustrate 
various embodiments in accordance with the present invention. The figures 
together with the detailed description, hereinafter below, serve to explain various 
principles and advantages in accordance with the present invention. 

FIG, 1 depicts, in a simplified and representative form, a block diagram of a 
10 communications system and prior art group management practices; 

FIG. 2 depicts, in a simplified and representative form, a communications 
system utilizing an embodiment of group definition according to the present 
invention; 

FIG. 3 illustrates in a simplified and representative form a communications 
15 system using an embodiment of group management in accordance with the 
present invention to facilitate setting up a conference call; 

FIG. 4 depicts the FIG. 3 system session routing after the conference call has 
been set up; and 

FIG. 5 depicts a flow chart of a method embodiment of setting up a 
20 conference call in accordance with the present invention. 
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Detailed Description of a Preferred Embodiment 

In overview form the present disclosure concerns communications systems 
that provide service to communications units or more specifically user thereof 
5 operating therein. More particularly various inventive concepts and principles 
embodied in methods and apparatus for the use and management of groups of 
such users are discussed, the groups being defined according to various call 
initiation protocols. The communications systems of particular interest are those 
being deployed such as GPRS systems or those being planned that employ IPv6 

10 such as 3 rd generation IP based systems or other systems using IP addressing and 
allowing for mobility of the communications services users. 

As further discussed below various inventive principles and combinations 
thereof are advantageously employed to essentially decouple group membership 
and the location or contact information (mobility) for the various members, thus 

15 alleviating various problems associated with known systems while still facilitating 
setting up sessions with or between groups of users regardless of present locations 
provided these principles or equivalents thereof are utilized. 

The instant disclosure is provided to further explain in an enabling fashion 
the best modes of making and using various embodiments in accordance with the 

20 present invention. The disclosure is further offered to enhance an understanding 
and appreciation for the inventive principles and advantages thereof, rather than 
to limit in any manner the invention. The invention is defined solely by the 
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appended claims including any amendments made during the pendency of this 
application and all equivalents of those claims as issued. 

It is further understood that the use of relational terms, if any, such as first 
and second, top and bottom, and the like are used solely to distinguish one from 
5 another entity or action without necessarily requiring or implying any actual such 
relationship or order between such entities or actions. Much of the inventive 
functionality and many of the inventive principles are best implemented with or 
in software programs or instructions. It is expected that one of ordinary skill, 
notwithstanding possibly significant effort and many design choices motivated by, 
1 0 for example, available time, current technology, and economic considerations, 
when guided by the concepts and principles disclosed herein will be readily 
capable of generating such software instructions and programs with minimal 
experimentation. Therefore further discussion of such software, if any, will be 
limited in the interest of brevity and minimization of any risk of obscuring the 
15 principles and concepts in accordance with the present invention. 

The present disclosure will discuss various embodiments in accordance 
with the invention. These embodiments include methods for managing 
membership and mobility for a group of users, initiating a session, and methods of 
setting up a conference call using or employing each or all of the aforesaid. The 
20 system diagram of FIG. 1 will be used to more fully explain a prior art system of 
group management and resultant problems, to develop common language 
conventions and thus to lay the groundwork for a deeper understanding of the 
present invention and advantages thereof. FIG. 1 in large part and at the 
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simplified level depicted is a representative block diagram of the relevant portions 
of a communications system 100, for example, a typical and known internet 
communications system or future such systems that may be any combination of 
wired or wireless systems. 
5 The system 100 is a wide area network (WAN) comprised of various 

interconnected domains such as domain A 101, domain B 103, etc.. The exemplary 
system of FIG. 1 as depicted will be explained in terms of such a system operating 
according to the Session Initiation Protocol (SIP) for call set up purposes. SIP is a 
typical call setup protocol particularly adapted for IP based networks. The 
1 0 domain A has a registrar 107, such as a SIP registrar and the domain B has a 
registrar 109, such as a SIP registrar each of which operate to keep one or more 
contacts in database 111, 113, respectively, for users registered with or under its 
domain and, according to SIP, one or more contacts for each member of any group 
with a name that indicates it is under the purview of that registrar. The registrar 
15 can be a server operating in accordance with appropriate protocols. For example, 
a SIP registrar would operate according to the SIP protocol with respect to call 
setup procedures. To review, a user name or group name under SIP is of the form 
sip: userl@domainA and sip: group2@domainA , respectively, whereas a user 
contact is of the form sip: userl@hostl. domain A (Note: hereafter the "sip:" will be 
20 dropped in the interest of generality and simplicity. It is understood that "sip:" is 
part of a SIP user or group or contact designation). The contact resolves the 
location of a user to a communications unit whereas a name does not and in the 
case of SIP merely resolves the domain or registrar where such information or 
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information leading to such information may be found. Returning to FIG. 1, each 
domain serves or provides connectivity and services to a plurality of hosts such as 
hostl 115 and host2 117 for domainA and host3 and host4 for domainB. The hosts 
are at least logical communications units, namely an IP address for a particular 

5 name and usually a physical device or communications unit such as a desk or lap 
top computer. However a user with a wireless device such as a PDA or laptop or 
cellular phone device may connect to domainA and be host2 when so doing or 
alternatively may connect to domainB and be logical host3 in that instance. A 
plurality of users with names such as userl@domainA 123, user2@domainA 125, 

1 o and user3@domainB 127 are served by the registrars 107, 109 and while normally 
located logically at a particular host are mobile or free to roam about the system 
100. 

FIG. 1 also depicts together with each registrar those users and groups that 
are registered with each registrar , specifically userl, user2, group2 and group3 

15 129 for registrar 107 and user3 and groupl 131 for registrar 109. Furthermore 
database 111 includes a contact or contact information for each of userl, user2, 
group2 and group3 133 and database 113 includes a contact or location for each of 
user3 and groupl 135. For example by observation, the contact or location for 
userl is user l@hostl. domain A and for user2 is user 2@hos t3. domainB. For a 

20 group whose name is, for example, group2@domainA there is contact information 
for each member of the group. In FIG. 1 this includes user2 and user3 for group2, 
userl and user2 for group3, and userl, user2, and user3 for groupl. 
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The contact or location information is placed in the database and updated 
using a SIP REGISTRER message originated typically by the user. REGISTER 
messages are the process used according to SIP that manages mobility for the 
respective users. For example, after user2 changes location from host3 to a new 
5 host, for example, host2, the user or the new host must send a sip REGISTER 
message that in form may look like REGISTER user2@domainA. Typically the 
message also contain a contact or end point header that specifies the new location 
where the user2 can be reached, specifically user2@host2.domainA , and an 
indication that the previous contact is no longer valid. According to the SIP 
1 0 protocol, user2's REGIST7ER message is forwarded to the registrar 107 of 
domainA. Registrar 107 would change the contact for user2 from 
user2@host3.domainB to nser2@host2.domainA . Repeating, these registration 
messages are the process by which SIP manages mobility for the users and many 
call setup protocols have analogous procedures. 
-1 5 in operation if userl wishes to set up a call or session with user3, userl 

sends, in SIP protocol, a SIP INVITE message to user3 which in form may look like 
INVITE user3@domainB from userl@domainA riPaddress_port#]. According to 
the SIP protocol userl's message is forwarded to domainA 101 and from there to 
the specified domain for user3, namely domainB or registrar 109. Registrar 109 
20 has contact or a location within its database for user3, specifically 

user3@host4.domainB and forwards the INVITE message to user3 at host4. By 
way of example a representative but simple INVITE message from Alice to Bob 
was copied from draft-ietf-sip-rfc2543bis-05 and is included below. One line to 
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note is the Via line and that includes the IP address, 10.1.2.3, and port #, 5060, at 
which Alice expects to receive a reply from Bob The reader is referred to the full 
document for further interpretation. The document is hereby incorporated herein 
in its entirety by reference. 

5 INVITE sip:bob@biloxi .com SIP/2.0 

Via: SIP/2 . 0/UDP 10.1.3.3:5060 
To: Bob <sip :bob@biloxi . com> 

From: Alice <sip : alice®at lanta . com> ; tag=1928301774 
Call-ID: a84b4c76e66710@10.1.3.3 
10 CSeq: 314159 INVITE 

Contact: <sip :alice@10 . 1 . 3 . 3 > 
Content -Type : application/sdp 

An INVITE to group3 from user3 would be of the form sip INVITE 
group3@domainA from user3@domainB [IP Port}. This message would be 

15 forwarded to domainA or registrar 107 and registrar 107 would forward the 
message to each contact for the membership of group3, specifically 
user l@hostl .domainA and user 2@host3 . domainB . One problem with this 
approach to group management is the large number of registration messages that 
the system must support when a user, such as user2 with the name 

20 user2@domainA chooses to move from host 3 in domainB back to host2 in 

domainA. This user will have to send a registration message to its own or home 
registrar plus a registration message to each registrar that is servicing each group 
where the user is a member. In this simple example when user2 moves at least 
four registration messages will need to be generated, one for its own registrar and 

25 one each for the respective registrar for each of 3 groups. Furthermore user2, 
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whomever, or whatever is charged with the registration updates will need to 
know every group where user2 is a member. 

Referring to the FIG. 2 depiction, of a simplified and representative 
communications system 200 we will describe an inventive embodiment, according 
5 to the present invention, of group definition and management that resolves the 
aforementioned problems. FIG. 2 in large part resembles FIG. 1 where like 
reference numerals refer to like items. This system is intended to operate with 
most general purpose call setup or initiation protocols but will be described with 
reference to SIP conventions for naming and call routing. The database 211 
1 0 associated with registrar 107 is different and includes different contents. The 

database still includes contact or location information for users that are registered 
with domainA but only contains names of members of the groups registered with 
domainA. Specifically contacts and names for, respectively, userl, user2 and 
group 2, group3 233 are maintained. The database 213 for registrar 109 is likewise 
1 5 different including contacts for users registered with domainB but only names of 
members for groups registered with domainB. Specifically contacts and names 
for, respectively, user3 and groupl 235 are stored and maintained. 

With this approach to group definition and management an INVITE from 
userl to group2 would go to registrar 107 and be forwarded to the names of the 
20 members of group2. Specifically user2@dom.ainA would be resolved by registrar 
107 to the contact or location user2@host3. domainB and forwarded to user2 on 
host3 while user3@domainB would be forwarded to registrar 109 and resolved by 
that registrar to the contact or location or end point user3@host4.domainB and the 
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INVITE would thus be forwarded to user3 at host4. 

A further difference is that one of the names of a member of group3 is 
alias 1 ©domain Alias . By the rules of the SIP protocol an INVITE directed to 
groupl@domainB will be forwarded to aliasl@domainAlias . FIG. 2 depicts a 
5 domainAlias 205, interconnected with domainB and domainA, with a registrar 206 
and database 208. The database includes a name for aliasl 237 that is 
userl@domainA , Thus an invite directed to aliasl would be redirected to the 
name userl@domainA and there be resolved by the registrar 206 to a contact or 
location of userl@hostl. domain A and thus forwarded to userl at hostl. 

1 0 This approach to group definition and management allows for 

independently managing membership for a group and mobility for members of 
that group in the communications system of FIG. 2. This method includes setting 
up a group name and a membership for that group including a plurality of names, 
each of the plurality of names indicative of a member or user within that group. 

15 This is accomplished, for example, in a SIP compatible system by sending a 
REGISTER message indicating the name and domain of the group, such as 
group l@domainB . The REGISTER message would also include a Contact header 
specifying the names of the members of group3, specifically alias l@domain Alias , 
user 2@domain A , and user3@domainB . Alternatively three RESISTER messages, 

20 one each for each member of the group could be sent with appropriate contact 
information for one of the members. 

Having set up the names for members of the group then establish 
separately and independently from the group membership contact or location 
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information associated with each of the plurality of names for the membership. In 
a SIP compatible system a REGISTER message to the respective domains can 
specify a contact such as user2@host3.domainB, u ser3@host4.domainB , or another 
name such as userl@domainA . In the last case a REGISTER message would need 
5 to be sent to domainA with the contact userl@host l .domainA in order to assure 
that messages for userl ©domainA can be routed to the proper end point or 
location. This method of setting up the membership including the plurality of 
names advantageously uses a name indicative of the user that points or leads one 
to a domain or registrar, for example sip: userl@domainA where a contact for the 
1 0 user or member will be found. As noted above an alias name can be used for a 
member or user. Note that this method of setting up the membership allows for 
the users to manage their mobility of for a third party to manage the membership. 

Also note that this method of defining and managing groups allows or 
provides for changing contact information without a corresponding change in 
1 5 membership information. By establishing the contact information as noted above 
a change to the contact information, specifically that portion providing for 
resolution to an end point or location, does not require a corresponding change to 
the membership information. By observation suppose user2 carrying wireless 
device 126 roams or moves from the locality of domainB at host3 to domainA at 
20 host 2. One REGSTRATION message changes the contact information at domainA 
to user2@host2.domainA and that is all that is required. No membership lists 
need to be changed. A user or member no longer needs to know the groups where 
they are a member. The registration load on the system is dropped to 25% of the 
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load in the prior art system of FIG. 1. In the real world it is not uncommon for a 
user to be a member of 10s and hundreds of groups so the actual savings in 
registration load is likely orders of magnitude larger than here described. 
Furthermore by always using the alias approach a user can change domains or 
5 service providers say from domainA to domainB and only have to send one 
REGISTER message to domainAlias rather than one for each group plus the 
service provider domain. The downside of the alias approach is perhaps 
somewhat longer call setup times as one extra communications link will be 
involved. 

10 To review suppose a userN@domainZ (not shown) wishes to use a call 

initiation protocol, such as SIP for initiating a session with members of a group, 
such as groupl. UserX would contact a first registrar, here registrar 109 of 
domainB with a request for a session with groupl, using, for example, an INVITE 
message defined according to SIP. This registrar will include a plurality of names, 

1 5 each of the names indicative of a member of the group and a second registrar 
associated with each of the names, here in sip form alias 1 ©domainAlias , 
user2@domainA, and user3@domainB . The request or INVITE will be forwarded 
to each of the second registrars associated with each of the names, here registrar 
107 after an intervening loop through registrar 206 for domainAlias and userl, 

20 registrar 107 for domainA and user2, and registrar 109 for domainB and user3. 
The second registrar will include a contact for the associated member, where the 
contact or contact information is indicative of a location or end point such as host 
or host address associated with each member, here hostl for userl, host3 for user2 
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and host4 for user3. The final step in initiating the session with the group is 
forwarding the request for a session to the location associated with each member 
of the group. 

The names used are preferably indicative of a member or user and a 
5 domain or registrar responsible for maintaining contact or end point information 
for the member all defined according to or compatible with SIP. This method as 
noted and described allows for forwarding the request for a session or INVITE to 
an intervening registrar defined by an alias name for one or more of the names 
indicative of the member and thereafter forwarding the request to the registrar 

10 with the contact for that user. Again the method allows for a change in the 
location or contact associated with a member but does not necessitate a 
corresponding change in the name associated with the member, thus allowing for 
mobility of the member or user or a change in location without necessitating a 
corresponding change to the name for the member. 

1 5 Note that the SIP protocol provides an alternative method of routing 

INVITE messages by redirection, rather that by forwarding. With redirection a 
registrar will retrieve the contact information associated with the destination name 
included with the INVITE and provide this information to the sender or originator 
of the INVITE. The sender then will send the INVITE message to the contacts 

20 supplied by the registrar. This alternative routing method is not so attractive 

because it is slower. However, it does support the use of the invention, allowing 
for mobility of the member or user or a change in location without necessitating a 
corresponding change to the name for the member. 
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Referring to FIG. 3, a simplified and representative communications system 
300 using an embodiment of group management in accordance with the present 
invention to facilitate setting up a conference call will be described. Much of FIG. 
3 is identical or similar to like elements / items from FIG. 1 and 2 so only the 
5 relevant differences will be discussed. Registrar 107 and 109 are shown with 

database 311 and 313. These databases while functionally similar to the databases 
of FIG, 1 and 2 have been given new reference numerals because their, respective, 
contents 333 and 335 have changed. In relevant part database 311 includes contact 
or location or end point information for userl and user2 333. Database 313 

10 includes contact for user3 and names representing the membership of groupl, 

namely userl@domainA, user2@domainA, and user3@domainB . In addition FIG. 
3 depicts a conference device 301 coupled to the registrar 109 and having ports A, 
B, and C. The conference device is a voice packet replication device like those 
currently being used in conference bridges and in dispatch systems such as those 

15 offered by Motorola in dispatch systems known as iDEN dispatch systems. The 
conference device is used when the group wishes to carry on a session that 
requires real time or near real time or time critical connectivity such as a voice 
conference or perhaps interactive video games or the like, typically a session 
utilizing Real Time Protocol (RTP). 

20 In operation suppose user3 wises to have a conference call with the other 

members of groupl. The Fig. 3 architecture and operation provides an 
advantageous approach to using a call initiation protocol, such as SIP, to set up a 
conference call on the conference device 301. This method includes receiving at a 
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registrar 109 from an originator, user3@domainB 127 a request for a call setup, 
depicted by dashed line 303, INVITE message in SIP parlance, among members of 
groupl, groupl being served by or registered with registrar 109. This INVITE 
message 304 includes [IP Jiost4] which represents a conference or voice IP address 
5 and port number that user3 anticipates using for the conference call. In some 
cases the originator will send the address and port in a later setup or transaction 
message. In any event this conference address and port are usually different than 
the setup or contact address and port used for signaling to establish the session. 
Preferably the registrar will communicate with the conference device 301 

1 0 and reserve one or more of ports A, B, and C for the group or conference call. The 
request or INVITE will be forwarded to each of the members of the group, userl 
and user2, through there respective registrar, here registrar 107, having the 
location or contact data for each member or user, together with a conference 
address of the conference device for each of the members, where the conference 

1 5 address is to be used by each of the members for the conference call. The 

forwarded request to userl and user2 is, respectively, depicted in FIG. 3 by dashed 
lines 305 and 307. Note that the INVITE message for userl 306 indicates 
[IP_CD„A] indicating that userl should use the conference IP address for the 
conference device and port A for the conference call. Similarly for user2 the 

20 INVITE message 308 indicates [IP_CD_B] indicating that port B on the conference 
device 301 should be used by user2 for the conference call. Preferably, the 
conference IP address and port number indicated by the originator, namely 
[IP_host4], will be removed from the request and replaced or substituted therefore 
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in the forwarded INVITE, as indicated, by the IP address and respective port 
numbers, A and B, for the conference device. Note that different users may get 
different IP addresses and port numbers, such as ports A and B, as here. This is 
often indicative of different communications capabilities for the users and thus for 
5 the ports on the conference device. For example users that are equipped to use 
multicast are likely to all get the same multicast IP address and port number for 
the conference device. 

The users 1 and 2 will respond to the INVITE with an OK message 
(not shown) for registrar 109 that includes their conference IP addresses and port 

1 0 numbers for the conference call. Registrar 109 will forward or provide the 

addresses, specifically conference IP address and port numbers for each member 
of the group, userl, user2, and user3, the originator, to the conference device. The 
registrar will also send a response, depicted by dashed line 309, to the request or 
an OK message 310 to the originator, user3, where the response or OK message 

15 includes a second conference address [IP_CD_C] of the conference device to be 
used by user3 for the conference call. This conference address, [IP_CD_A] is a 
conference or voice IP address, IP_CD, and port number, C. Note in this case 
where the originator, user3 is a member of the group according to SIP the original 
INVITE will be forwarded or sent back to this user. If desired this mechanism 

20 could be used to communicate the conference device address and port to user3. 

Thereafter as depicted in FIG. 4 all participants in the conference call now 
use the conference device for session routing after the conference call has been set 
up. As depicted user3 uses the two way link shown as dashed line 401 to 
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communicate to/from the conference device and userl and user2, respectively, 
uses the links, depicted by dash line 403 and 405. This is possible since all parties 
to the conference call now have the proper conference information, specifically 
conference IP address and port numbers as a result of the session or call initiation 
5 procedures described above. Note; another way to support voice replication in a 
group call is to use multicast. In networks that support multicast, there is no need 
for a conference device such as device 301. Either the originating user3@domainB 
or the registrar would specify the multicast address and port number that is to be 
used by all participants and include it in the INVITE and OK (response to INVITE) 

10 messages as described above. 

Referring to the FIG. 5 flow chart a method of setting up a conference call 
will be described. Much of this description is a review of the above discussion and 
should be read in conjunction therewith. The FIG. 5 method 500 begins at 501 and 
shows receiving, at a central point or preferably at a registrar from an originator, 

15 such as user3, a request for a call setup (preferably along with the originator's 
conference IP address and port number for the conference), such as an INVITE 
message in SIP, among members of a group, such as groupl, serviced by the 
registrar. The registrar will include names for each of the members of the group 
where preferably the names are compatible with SIP and are indicative of each of 

20 the members and a member registrar for each of the members that includes a 
location for each of the members. 

At 503 the registrar communicates with the conference device and reserves 
resources such as port numbers typically according to the various 
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communications capabilities of the respective members of the group. At 505 the 
request is forwarded to each of the members of the group, via there respective 
registrar and the location information therein, together with a conference address 
(IP address and port) of the conference device for each of the members, this 
5 conference address is, preferably, substituted for the originators conference 

address and is to be used by each of the members for the conference call. At 507 
responses are received from group members with their conference IP /port 
information. 

At 509 the conference IP /Port information for each member and the 
10 originator is provided to the conference device. At 511 the registrar sends a 
response to the request to the originator, the response including a second 
conference address of the conference device to be used by the originator for the 
conference call. At 513 now that all participants including the conference device 
have all requisite IP addresses and port information all participants in the 
15 conference call will use the conference device for the conference call. 

The processes, discussed above, and the inventive principles thereof are 
intended to and will alleviate problems caused by prior art group definition and 
management. Using these principles of defining groups and managing those 
groups will simplify modifications of the various group memberships and the 
20 network traffic associated with changes to a members location or contact or end 
point and thus facilitate connectivity for mobile professionals. One of the 
principles used is using group membership designations that are separate and 
independent from member contact information so that changes in end point or 
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contact information does not necessitate a change in each groups membership. 
This dramatically reduces network traffic require for registration activity when a 
user or member moves from one network domain to another. 

Further the individual member does not have to know every group where 
5 they may be a member. The risks associated with incorrect registration messages 
are reduced as the user or member no longer needs to send a new registration 
message to each registrar serving a group where they are a member when there 
end point location changes. It becomes practical to have a membership manager 
or agent maintain group membership and remove that burden completely from 

10 the end user. As we have noted the burden with maintaining group membership 
lists may be further reduced by using an alias SIP name and registrar so that even 
in a change in home domain, such as a change in service provider will not create a 
significant burden for group membership management. 

Various embodiments of methods, systems, and apparatus for managing 

1 5 group membership so as to facilitate and provide for group calls in an efficient 
and timely manner have been discussed and described. It is expected that these 
embodiments or others in accordance with the present invention will have 
application to many wide area networks that provide for mobility of their user or 
subscriber devices or units as well as wireless local area networks that are coupled 

20 to fixed WANS such as the PSTN or internet. For example wireless systems in 
which the registrar functionality is embodied in a Home Location Register (HLR) 
would be ready candidates for using this invention or equivalents thereof. In the 
HLR one would set up a group name and membership for that group including a 
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plurality of names, each name indicative of a user within the group. Each name 
can be set up in the form of an International Mobile Subscriber Identity, which 
resolves into a phone number of the users communication unit. This number 
would resolve through the use of Global Title Translation, into the HLR registrar 
5 of the users communication unit. This disclosure and the inventive principals 
herein extends to the constituent elements or equipment comprising such systems 
and specifically the methods employed thereby and therein. Using the inventive 
principles and concepts disclosed herein advantageously allows or provides for 
low latency and low network overhead access to contact information for groups of 

10 communications units or devices and procedures for maintaining such 
information which will be beneficial to users and providers a like. 

This disclosure is intended to explain how to fashion and use various 
embodiments in accordance with the invention rather than to limit the true, 
intended, and fair scope and spirit thereof. The invention is defined solely by the 

1 5 appended claims, as may be amended during the pendency of this application for 
patent, and all equivalents thereof. 
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